the key should be stored in a versioning system?

Would it make any sense for the SLSA.dev website to accept these attestations and keys in this repository for storage + reference? (Maybe instruct the build system owner to include it in the PR mentioned below in step 4?)

should ask. Will the collection of metadata require versioning? Will main be the ground truth or will folks cut release every X months to release? (have to be careful how this plays with revocation)

What do you think of the ideas stated here around keys: #590 (comment) #590 (comment)

Do you think that either of these options would help to satisfy the need for immutable data but also revocation? I hate the idea of a build system owner having to come to our repo and update the version of their key if it get's revoked or expires. It seems like it is a process that is highly vulnerable to human error.

PKI is definitely better since it pushes the problem to a CA instead of us. One thing to think about, though, is verification. PKI was built for "online" verification, where the client wants to verify that the cert is valid at the time of the connection.
Provenance verification happens "offline", ie a client wants to verify that the provenance was signed at a time where the certificate (and the builder attestation) was valid. This requires to have a log of "time of a signature" like Rekor provides. If you want to support key rotation, you need this feature or a client would always reject provenance signed with a certificate that is expired at verification time.

I must admit that I don't understand certificate transparency all that well. It would help prove a certificate hadn't expired at the time of signature but not whether the certificate had been revoked, right? IIUC, Sigstore uses very short-lived certificates by design, so revocation isn't part of the design, so even if we require CT for the build system PKI we need a way of handling revocation. Is that right? Or could we just punt revocation to the CAs in the case where builders don't use Sigstore?

CT in general just stores certs, not time of signatures: this works fine for web PKI / TLS (including key rotation), because verification happens "online". Rekor does store time of signatures, which enables "offline" revocation + key rotation (ephemeral keys are just short-lived rotated keys).

You're correct that Sigstore does not support revocation today, I think there are efforts to build some mechanism "on top" of Sigstore.

I think you mentioned we should replace the word conformance with compliance in the spec meeting today

Although the two terms conformance and compliance are often used interchangeably the right term to use is conformance (along with conformant).
I suggest use this consistently throughout our documentation.

https://wikidiff.com/conformant/compliant for instance states that:
the difference between compliant and conformant is that compliant is willing to comply; [...] while conformant is in accordance with a set of specifications.

We should have a way to support build systems that use multiple keys.

Two ideas come to mind: either supporting multiple public keys per certification or switching to x509 certs and treating all certs that chains up to the one in the registry as being from the same builder. I suspect the x509 option is over engineered for the moment, but it makes it easier for build systems to add new worker nodes without reusing keys. WYDT?

I think using x509 certs is the cleanest option (from a user perspective) but it is definitely more difficult from an implementation perspective.

I would love to be able to point to a "root CA" for lack of a better term that each build service owner maintains.

Yes, that's exactly the model I had in mind. Each build service (or maybe build service type if an owner operates more than one) is the root CA, and they mint certs for each worker they spin up. The problem is that it feels unreasonable to ask a build system operator also to run a CA, or at least it limits the PKI option to organizations of a certain size. That's why we should also have a keyless option with Sigstore.

The registry should also support keyless provenance signing with Sigstore. I think the OIDC issuer + Subject Alternate Name should be enough to identify a builder.

^ that is a great idea! Do you think that this would scale better than the x509 idea?

Should we standardize on one or offer both as options?

Sigstore is a CA (Fulcio) using x509 certs for users. It's basically an "instantiation" of the idea

We should support both Sigstore and more conventional PKI. Sigstore is easier to use, but I don't like the idea of forcing SLSA builders to use Sigstore.

I think that's a fair point- maybe its to the extent that we recommend Sigstore and show how to do the steps- but also allow/support other options as well.